-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using wrappedToken in CompositeLiquidityRouter in ERC4626Pool operations #1201
Using wrappedToken in CompositeLiquidityRouter in ERC4626Pool operations #1201
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First pass done. I didn't get to the tests yet, but I think there are a few things that need to be adjusted before proceeding.
Overall the idea is correct; great job. It's just that some of the edge cases should behave differently now that we're not automatically wrapping / unwrapping.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another pass done.
Changes are looking good for the most part. Just a few minor comments around names / docs / style; otherwise seems to be correct. I'll finish covering the tests in one more pass. Great job!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a pretty elegant solution (especially to the limits problem). I have a conceptual issue with the useWrappedTokens
name, and lots of little details.
I also think these PRs need a lot more in the description. Why do we need it? What problem does it address? What options did we consider and reject (e.g., in this case, the limits hack, replaced by splitting the wrap/unwrap functions)?
Otherwise we're not going to remember all this context when we go back and look at this in 6 months or a year.
Co-authored-by: EndymionJkb <[email protected]>
Co-authored-by: EndymionJkb <[email protected]>
Co-authored-by: EndymionJkb <[email protected]>
Co-authored-by: EndymionJkb <[email protected]>
Co-authored-by: EndymionJkb <[email protected]>
Co-authored-by: EndymionJkb <[email protected]>
Co-authored-by: EndymionJkb <[email protected]>
Co-authored-by: EndymionJkb <[email protected]>
Co-authored-by: EndymionJkb <[email protected]>
Co-authored-by: EndymionJkb <[email protected]>
…ttps://github.com/balancer/balancer-v3-monorepo into using-wrapped-amount-in-erc4626-operations-in-clr
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to address the boolean array name (see my suggestion to use isStandardToken
or useAsStandardToken
), and returning the token addresses, which would resolve all the "sorted in ... order" comment issues.
My eyes are already lost in the description, I double checked several times, but if you can double check, I would be very grateful |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking much better! Note the suggested language for NatSpec, which I believe is much clearer.
Sorry for the late comment, but I feel we're making up new terms here 😅 We're already dealing with wrapped and underlying, and that should be enough. I can't know which of them is The argument is consumed by a function called |
Makes sense - especially because there isn't an unwrap, so there's only one name for the set of flags. The only drawback is the "default" value would be to set everything to true (kind of annoying), but I agree that reusing standard terms is more important. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking great.
Just a few more comments; otherwise LGTM. I like the new structure much better; it reuses less code, but it's more clear and goes straight to the point.
Co-authored-by: EndymionJkb <[email protected]>
Co-authored-by: EndymionJkb <[email protected]>
Co-authored-by: EndymionJkb <[email protected]>
Co-authored-by: EndymionJkb <[email protected]>
Co-authored-by: EndymionJkb <[email protected]>
Co-authored-by: EndymionJkb <[email protected]>
…ttps://github.com/balancer/balancer-v3-monorepo into using-wrapped-amount-in-erc4626-operations-in-clr
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good now; have one last (very minor) rename suggestion, and some comments.
pkg/vault/test/foundry/CompositeLiquidityRouterERC4626Pool.t.sol
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A bit late, but for the record the latest changes are looking good. Great job @elshan-eth !
Description
The current CLR implementation does not support adding mixed assets. For example, if my pool consists of two wrapped tokens, and I already have one of them and want to use it, this is not possible with the current CLR. The reason is that it treats all input tokens as underlying assets. This PR resolves the issue by introducing a new flag in the interface, allowing us to specify which type of token to use.
Type of change
Checklist:
main
, or there's a description of how to mergeIssue Resolution
Closes #1192